We can't just remove the old keys as that would be a breaking change in the protocol. The best thing to do would be to leave them, add a # DEPRECATED: comment indicating that they will be removed eventually, and add the new boundaries key in addition to the existing ones.

Somehow I thought they were already marked as deprecated though.

@Askaholic @BlackYps What do you think about sending a list (set) of means instead of boundaries? Then the client can decide for itself what range it wants to use

That sounds like a good idea

Yea that sounds better to me too. I guess another thing to consider is should we be sending the party information in some way or just sending a flat list of means?

Or another idea would be to send something similar to a histogram to prevent the message from scaling with the number of players in queue. Something like this where the means are just rounded to the nearest 100:

{
    "summary_means": {
        400: 1,
        600: 2,
        1000: 4,
        1400: 1,
    }
}

You're right we should probably send the party mean instead of each players rating as the partys are matched by their average resting only. If a 1k and a 2k form a party they need other 1500s in the queue to match.

We don't need the number of players in a chunk, only if a chunk is populated at all. We could do it like this but 100 is probably a bit too coarse. How big of a deal is it anyway when the message size varies?

Does not removing the old keys to stay protocol compatible also imply that they should still send the same info?
Breaking changes were planned for v2 of the server, right?

Message size varying is fine, I want to make sure however that we think about the different ways that we could be encoding the information that the client needs and sending it in the most byte efficient way. More bytes means more CPU load on the server and more potential to run into bandwidth issues. If we can pass the same information in a way that avoids the possibility of scaling infinitely then I say we should go with that.

The protocol versioning is more about the structure of messages and not so much about the content. If certain messages start sending empty lists that used to be non-empty, that should be fine as the client should be able to handle that case anyway. Some feature of the client might stop working by showing empty results or just not appearing anymore, but it doesn't cause the client to break (crash) due to serialization errors or trying to perform operations on an incorrect type.

Another thing that we've learned from experience over the years is that sending info in the form of a dict with descriptive key names is preferable over sending a list where you need to know what the data in the list means. This is because with dicts you can easily add more keys if you need to extend the message without breaking the existing functionality.

This might be fine in this case. I think we should rename ratings to something a bit more specific though as there is also a key in the player_info message called ratings which has a different structure from this. Maybe something like rating_buckets, rating_groups or something? Also would it be useful to send the granularity?

maybe active_rating_groups? when I hear rating_buckets my first thought is that the list contains all eligible rating buckets and all buckets not listed are invalid, whatever that means.
I don't think it's useful to send the granularity. As long as the granularity is reasonably high it doesn't really matter for the client. And if we rounded to something unreasonably coarse like nearest 200 rating then the entire list would be useless anyway.

Would it make sense to add a config value for the granularity?

I don't see a reason for this. We should choose a reasonable value once and then there is no real reason to change it on the fly. I will extract the number into a variable though to make it less of a magical number.